@TylerHelmuth shouldn't we use OTEL_METRICS_EXPORTER as otlp and then set OTEL_EXPORTER_OTLP_METRICS_PROTOCOL as http/protobuf for latest release to avoid warning logs which can be confusing for end users?
I think the same should be done for traces. It will make env vars configuration to be conformed with specification. What you think? :)

@mat-rumian sure I can make that change.

Shall we as well change this comment in the requirements

So do I get it right that the exporter will use proto over HTTP and not gRPC?

Shall we as well change this comment in the requirements

opentelemetry-operator/autoinstrumentation/python/requirements.txt

Line 2 in 2ea988c

# We don't use the distro[otlp] option which automatically includes exporters since gRPC is not appropriate for

?
So do I get it right that the exporter will use proto over HTTP and not gRPC?

We didn't use gRPC from the beginning. PR just changing the way exporter is configured. Previous configuration was setting up exporter to use proto and HTTP in single environment variable OTEL_TRACES_EXPORTER (like otlp_proto_http).
OT Python community developed support for configuration described in the OT Specification - so OTEL_x_EXPORTER which defines the exporter (e.g. zipkin, jaeger, otlp) and OTEL_EXPORTER_OTLP_x_PROTOCOL which defines protocol (e.g. grpc, http/protobuf, http/json).

@frzifus @pavolloffay @mat-rumian the e2e tests highlighted an interesting scenario that my code wasn't handling. Originally I was only setting the protocol when the exporter also needed set to otlp, but this doesn't work when the user has already set the the exporter to otlp themselves.

I've updated the code to be less intelligent and always set the otlp protocol env var if it is not set. This env var is unncessary when the exporter is set to something other than otlp, but it also shouldn't hurt anything. We could go the extra step and only set the protocol if it is not set AND the exporter is set to otlp, but that feels a little flimsy. I think always setting the protocol if it is not set will be more flexible as the spec/python auto-instrumentation finalize.

Please re-review.